Cool! Thanks for the heads up @luz I've made a github issue to track this update: https://github.com/OnionIoT/OpenWRT-Packages/issues/106 For now the plan is to make this updated driver available in the new 23.05 firmware. Does anybody have a specific need to have this available in the older v0.3.4 firmware??

@Paul-Chabot: From the datasheet you linked, these UCS1903 chips are close relatives to the WS281x family of LED chain chips. To generate the required signal with SPI, you'd need to have a SPI interface available exclusively for the purpose (which you don't on Omega2), and you need to have tight control of the SPI to send a long uninterrupted stream of data (which usually works on Arduino&Co, but is difficult on a Linux system). But luckily, there's hardware better suited for the task than the SPI in Omega2's MT7688 chip: the PWM unit. It's still a bit tricky to meet all timing constraints, but definitely possible. I know because I wrote a kernel driver named p44-ledchain exactly for the purpose I needed it for Omega2 based projects like this (with 200 WS2813 LEDs). Now, the UCS1903 has slightly different timings specs than the chips already supported in p44-ledchain (WS2811, WS2812, WS2813, P9823, SK6812). Still, I think it should work with the P9823 setting. If not, just let me know and I can add another option for the UCS1903 chip to the driver. If you want to give it a try: Install the driver (needs --force-depends because there's no 100% kernel version match): cd /tmp wget http://plan44.ch/downloads/experimental/kmod-p44 ledchain_4.4.61%2B0.9-2_mipsel_24kc.ipk opkg install --force-depends kmod-p44-ledchain* Then load the driver and configure it for a chain of 100 P9823 (see here for detailed description of the module parameters): insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain0=0,100,3 Now you need to configure one of the GPIO pins to provide PWM0 output (GPIO 18 or 46 have that option): omega2-ctrl gpiomux set pwm0 pwm; # for GPIO 18 omega2-ctrl gpiomux set uart1 pwm01; # for GPIO 46 Finally you need to connect your DIN of the first UCS1903 in the chain to the PWM0 output pin of the Omega2 (GPIO 18 or 46). As the Omega2 is 3.3V and the UCS1903 is 5V powered, the high level coming from the Omega2 might not be sufficient for the UCS1903. In my experience with WS281x chips, it can work sometimes, but not reliably. So the right way to do it is adding a level shifter such as a 74AHCT1G125. Now you can just write a string of RGB values into /dev/ledchain0 to control the LEDs, for example: echo -en '\xFF\x00\x00\x00\xFF\x00\x00\x00\xFF' >/dev/ledchain0 to make the first LED red, second green, third blue. There's more info and details in this forum thread

@dmynerd78 have a look at using PWM to drive the RGB lines of the LED's - the Omega has a simple command line to drive PWM. https://onion.io/2bt-fast-gpio-pwm/ You could probably use the Omega GPIO's through open collector transistors or mosfets to drive the LEDS, then you won't have to worry about the 5V supply as it is isolated from the Omega's 3.3V. Read up on which GPIO pins to use though as some have special functions and you need to disable them using the omega2-ctrl gpiomux command https://docs.onion.io/omega2-docs/using-gpios.html

I get a following error: Traceback (most recent call last): File "bitcoin.py", line 27, in <module> a=json.loads(jsfile) File "/usr/lib/python2.7/json/init.py", line 339, in loads return _default_decoder.decode(s) File "/usr/lib/python2.7/json/decoder.py", line 364, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded I modify the line27 - but the error is same: Traceback (most recent call last): File "bitcoin.py", line 27, in <module> a=json.loads(jsfile)[0] Can you help for me, how could I fix it? Thanks a lot!

You need a arduino library for ws2815 led strip,you can study it from here. https://forum.arduino.cc/index.php?topic=405287.0

I tried a number of solutions. Here’s what worked and what didn’t. “Worked” here means that the Omega2 booted correctly and then successfully drove the DotStar LED strip via the SPI interface using Python code linked above. • Diode level shifter (description, circuit did not boot This article has several ideas for interfacing: Exploring Edison - Life At 1.8V. From that article: • Single transistor non-inverting (circuit did not boot • Two transistor, non-inverting (circuit worked! MOSFET level-shifter (description). I found two commercial implementations: • 4-channel I2C-safe Bi-directional Logic Level Converter - BSS138 • SMAKN 3.3V To 5V 5V To 3.3V 4 Channel IIC I2C Logic Level Converter But neither of these worked. Finally, I tried a chip designed for this purpose, a 74AHCT125. I used a DIP version to breadboard: 74AHCT125 - Quad Level-Shifter That worked, so following this post, I soldered a 74AHCT2G125DP,125 (SOT8) onto an SMT Breakout PCB. That was easy to wire into a DotStar connector. I found that I had to connect the output enable pins of the 74AHCT2G125 to ground. That surprised me, as I expected that they would have to driven by the Omega2 SPI CS1 pin, allowing the Omega2 clock and data pins to float while the Omega2 was booting. But with the OE lines soldered low, it worked, booting and then driving the LEDs via SPI. I soldered the pins of a mini-expansion board as described in the original post above, wiring the +5V from the DotStar power supply, via the connector cable to the 5V pin of the USB A socket on the mini expansion board. It's large enough to be probed/soldered to. [Note: With this setup, power is now supplied by an external supply. Do not connect to a laptop using either USB port.] I sent this question to Onion tech support, but received only a note that it would be forwarded to technical staff. it looks like the Omega2 headers are labeled "A" and "B" and numbered left to right. Diagram here